Portal is a term for a World Wide Web site that is a major starting site for users when they get connected to the web or that users tend to visit as an anchor site, linking to many other sites. The portal refers to the virtual “door” that a user walks through every time the user wants to access the Internet; this is the first screen that a user sees when going online. A portal as a Web site “gateway” provides multiple services, which could include Web searching capability, news, free-email, discussion groups, online shopping, references and other services and sometimes a community forum. Although the term was initially used to refer to general purpose sites, it is increasingly being used to refer to vertical market sites that offer the same services, but only to a particular industry such as banking, insurance or computers. A more recent trend is to use the same term for sites that offer services to customers of particular industries, such as a Web-based bank “portal”, on which customers can access their checking, savings and investment accounts. The first Web portals were online services that provided access to the Web, but by now most of the traditional search engines have transformed themselves into Web portals to attract and keep a larger audience. Some portals offer users the ability to personalize that web site according to individual interests. Portals provide a secure, single point of interaction with diverse information, business processes, and people, personalized to a user's need and responsibilities.
The building blocks of portals are portlets, which are held in containers, which in turn are contained by a portal page. That means that a portal consists of pages which include containers which in turn are composed of portlets. A portlet can be regarded as a pluggable user-interface component to provide a presentation layer to an information system. The portlet container, the portlets' runtime environment and a core component of each portal requires knowledge about the portal itself and must reuse common code from it. Consequently, the portlet container remains completely separated from every other portal component. Portlets contain portions of content, that means single applications, and markup languages such as HTML (HyperText Mark-up Language) and XML (eXtensible Mark-up Language). A portlet can be described as a small window on a portal page. The portlets can be minimized and often comprise consistent help and configuration menus. Portlet technology allows a portal page to be customized more quickly either internally by a development team or by an end user. Portlet technology can come as an adjunct to a portal server or as optional interfaces to ERP (Enterprise Resource Planning) applications. The degree of customization also varies. Portlet windows can be entry points to a variety of services. Functionalities of a specific portlet are adopted from the portlet's own configuration. A portlet is an integration component between applications and portals that enables delivery of an application through a portal.
A bookmark portlet provides, for example, a way to store names and URLs (Uniform Resource Locators) of Web sites. After a bookmark is created, clicking the link opens the site in a new browser window of a corresponding display of a computer. The bookmark portlet shows all of the bookmarks in a folder of a user's choosing.
Specifications which are relevant for portals are JSR-168 (Java Specification Request 168) and OASIS-Standard WSRP (Web Service for Remote Portlets). Most portal solutions are programmed using Java, thus achieving best system independence (Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both). A portlet is a small program written in Java and usable as an add-on of the corresponding portal. On client side, portlets are represented within a browser as an easy manageable user interface with icons for maximizing, minimizing, editing and for help. Internally, namely on server side, any application can be lodged which transfers its presentation to the portlet. Portlets provide a way of dividing development tasks and incrementally developing the capabilities of a site. Portlets represent discrete pieces of functionality that can be written and deployed over time.
Today portlets are mainly installed by portal administrators. Moreover, pages acting as the containers for a set of portlets are assembled by portal administrators, too. As already described above, a portlet is a web component, that provides access to web-based content, applications, and other resources. A portlet can process requests and generate dynamic content. Portals use portlets as pluggable user interface components to provide a presentation layer to information systems. Portlets may be represented by a text hyperlink or a graphical icon located beside or above such a text hyperlink. The appearance, the design and the functionalities of a portlet are defined by and based on the portlet's own configuration data. The configuration data can define, in principle, all information and properties of a portlet, even its optical design such as its height, width, background and font, and also functional properties. The configuration data are stored in the so-called portlet descriptor. During the deployment those initial configuration data are used and disposed in a local database. The configuration data can be supplemented by user actions. Those non-initial configuration data are also stored in the already mentioned local database. Usually portlets are not pre-configured, as the portal administrator is not interested in using these portlets in some business context, nor does the administrator have the knowledge and/or time to pre-configure each portlet he installed meaningfully for every single portal user or user group.
This leads to scenarios where every portal user has to configure a portlet themselves, even if other portal users within the same portal community might already have done some similar portlet configuration. Letting more than one user within a portal community perform similar configuration tasks of portlets used, costs time and hence money due to the fact that the similar work is done redundantly. Besides that, there might be users acting in the same portal community which do not know how to configure a certain portlet within the portal community accordingly. Such users would highly appreciate a meaningful pre-configuration of the portlets they want to use.
An exchange of pre-configuration data could also increase the value of a certain portlet, as more people set meaningful preferences and make the portlet itself more powerful because of a queued exchange of preferences. This could also allow for versioning of pre-configuration data always allowing users to decide which version to apply/use.
Currently, portlet configurations or portlet configuration data can only be exchanged among users within a portal community by means of a phone call or by exchanging mails on the basis of which a manual synchronisation of the portlet configuration can be performed. Moreover, configuration data of pre-configured portlets cannot be exchanged due to the fact that portals utilize a centralized administration model and provide no way for decentralized exchange of portlet configuration data.
Therefore, it would be desirable to provide a method for exchanging portlet configuration data among portal users.